1. Field of the Invention
The present invention relates to a method and apparatus for performing fast interprocess communication in the kernel mode of an operating system. Specifically, the method involves implementing common data structures as an abstract data type termed a "resource." The resource is a general mechanism for kernel mode resource allocation, deallocation, and signaling. Data structures derived from the resource data type may be used by participants to facilitate object calls across heterogeneous systems.
2. Background
Distributed object computing combines the concepts of distributed computing and object-oriented computing. Distributed computing involves two or more pieces of software sharing information with each other. These two pieces of software could be running on the same computer or across different computers connected via a network connection. Most distributed computing is based on a client/server model. With the client/server model, two major types of software are used: client software, which requests information or a service, and server software, which provides the information or service.
Object-oriented computing is based upon the object model of computer programming where pieces of code termed "objects" own data (termed "attributes") and provide services to other objects through methods (also known as "operations" or "member functions"). The data and methods contained in an object may be "public" or "private". Public data may be altered by any other object. Most data, however, is private and accessible only to methods owned by the object. Typically, the object's methods operate on the private data contained within the object.
A collection of similar objects makes up an interface. An interface specifies the methods and types of data contained in all objects of the interface. Objects are then created ("instantiated") based upon that interface. Each object contains data specific to that object. Each specific object is identified within a distributed object system by a unique identifier called an object reference. In a distributed object system, a client sends a request (or "object call") containing an indication of the operation for the server to perform, the object reference, and a mechanism to return "exception information" (unexpected occurrences) about the success or failure of a request. The server receives the request and, if possible, carries out the request and returns the appropriate exception information. An object request broker ("ORB") or similar intermediary provides a communication hub for all objects in the system passing the request to the server and returning the reply to the client. Object calls may be implemented across systems ("intercpu calls") or across processes within a single system ("interprocess calls").
The ability to perform fast intercpu or interprocess calls (collectively, "cross-domain object calls") is a necessary foundation for any commercially viable distributed object system. To provide fast cross-domain object calls, a distributed object system must operate in the kernel mode of the operating system. Operating systems typically have two modes: user mode and kernel mode. The distinction between the two modes involves memory addressing and instruction levels. In user mode, each process operates in a separate memory address without the ability to disturb the address of other processes. In kernel mode, no addressing restrictions are placed upon processes. To perform fast cross-domain calls, the operating system must operate in the kernel mode. Kernel mode operation ensures the availability of certain resources that would otherwise not be available to perform object calls. Moreover, purchasers of the distributed object system are assured that the integrity of the overall mechanism has the same integrity as the operating system.
Interprocess communication is typically performed in kernel mode between processes executing on separate machines, although the processes may execute within the same machine. In a classical object call, a first process (a "client process") requiring a specific service attempts to call an object within a second process (a "server process"). The server process usually is allocated a process control block by the operating system. The process control block has a message queue for receiving messages from other processes. Once a call is made by the client process, the call is queued onto the message queue. A low-level routine (such as an "awake" or "signal" routine) within the operating system "wakes up" the server process. The server process can then properly implement the call. Finally, the file system dequeues the message.
The classical approach to interprocess communication has certain drawbacks. First, users of the system are forced to use a particular transport layer. Iona's Orbix, for example, uses TCP/IP as its transport layer. Thus, cross-domain calls are performed using the TCP stack. This requirement is disadvantageous since many real-world application scenarios are thereby precluded. In addition, this requirement may be costly since users who do not use a particular transport are forced to purchase that transport layer. Second, implementations are usually tied to a particular operating system. This operating system-dependency arises from the fact that the kernel mode on each OS is different. Accessing the kernel mode in Windows NT, for instance, is very different from accessing the kernel mode in UNIX. Rather than provide kernel mode support for several operating systems, interprocess communication is usually tightly coupled to one operating system. Thus, users are forced to use a single operating system throughout their network. In many instances, such single operating system networks are not viable.
Accordingly, a need exists for kernel mode support of fast interprocess communication.
Moreover, a need exists for such kernel mode support to operate independently of transport layers and operating systems.